1. Field of the Invention
The present invention relates to a system and a method for obtaining response times for exception response applications. More particularly, the present invention relates to a system and a method by which a network performance monitor is able to collect response times for transactions on a network which involve an exception response application without creating protocol violations in the network.
2. Description of the Related Art
Today, networks are commonplace tools which are employed to permit users of the network to access to a wide variety of information and computer resources. Commonly, a powerful computer, such as a mainframe, lies at the heart of a network. A communication access means (CAM), such as VTAM, which is a trademark of the IBM Corporation, is employed to operate the network. The CAM harnesses the power of the mainframe for multiple users, and the CAM permits each user to access the resources associated with the mainframe, such as terminals, printers, applications running on the mainframe and numerous other peripheral devices.
Networks can be employed in many different environments. Accordingly, the needs and requirements of users, owners or operators of each given network may be quite different. In this regard, a need developed to modify each CAM to meet the needs of the users of the particular network. In response to this need, network performance monitors (NPMs) were introduced to monitor the performance of CAMs in order to provide a means for determining whether the CAM is controlling the network in a manner which is most expedient for the users, as determined by the users. NPMs obtain transit time and volume statistics from CAMs for given resources and/or applications associated with the CAM and process this data to provide performance data, which is used for many purposes. For example, a CAM operator may use the performance data to modify the CAM so as to better serve the requirements of the users. Based on this data, the operator can speed up certain functions, change priorities, provide more equitable access to certain resources, etc.
However, one major drawback to the use of NPMs is that CAMs and applications and resources were not designed with NPMs in mind. NPMs were designed, therefore, to tap into CAMs in order to obtain statistics which can be processed to obtain appropriate data regarding the operation of the CAM and the interaction between the computer, the applications, the users (terminals) and the various resources of the network. For example, when a user at a terminal is using a CAM to access and run an application on the network, the total time or operator time involved is calculated by an NPM by summing host and network times for a given transaction involving the terminal and the application. However, this technique does not readily work when an application is running in exception response mode. The technique works effectively when the application is running in definite response mode. When in definite response mode, a user at a terminal initiates a transaction by sending a request or message (an inbound request path information unit or inbound PIU) to the application (via the CAM). The application processes the request and responds by sending a message (outbound PIU) to the terminal (via the CAM). The terminal notes its reception of the message by sending an appropriate message (inbound definite response PIU) to the application (via the CAM). The passage of each message through the CAM is detected and data associated therewith noted by the NPM. The NPM then processes the data to calculate response times including the host time, which is the time between the passage of the first and second messages, and the network time, which is the time between the passage of the second and third messages.
However, the sending of the definite response PIU adds no additional transfer of real data when the second message was received without error by the terminal, which occurs most of the time. Further, the sending of this third message means that about 33% more CAM, bus, and network time is used than would be used if just the first two messages were sent. On busy networks, use of the third message tends to slow the network significantly. Accordingly, applications were developed that run in what is known as exception response mode. In exception response mode, a third message from the terminal back to the application is sent only if a problem exists with the second message as received by the terminal from the application. However, when an NPM is gathering statistics for a transaction and an application running in exception response mode is involved in the transaction, the NPM is unable to obtain the data necessary to calculate the network time and thus the operator time.
To date, NPMs have attempted to resolve the problem caused by the lack of a third message for transactions processed by exception response mode applications by creating a third message in the network itself. Typically, the NPM intercepts the second message in the CAM and alters the second message so that it appears to the terminal that the application is running in definite response mode. Accordingly, the terminal generates and sends the third message. The NPM then intercepts the third message in the CAM, records the time it was received (and any other desired data) and discards the third message within the CAM before it reaches the application. However, significant problems exist with this technique. A significant percentage of these changes result in the protocol violation in the network which causes a session between the application and the user whose session is being monitored to hang or drop entirely. These protocol violations occur when, for example, the NPM loses track of which PIU was altered. Thus, the created PIU will not be intercepted and discarded, and, when such a PIU is received by an application in exception response mode, a protocol violation occurs. Further, it is not uncommon for the NPM to alter the wrong PIU or intercept and discard the wrong PIU, both of which will also result in protocol violations. Additionally, even on networks, the time it takes for a message to travel may not be insignificant, particularly if satellites are used to send messages. And, it is not uncommon for the application to send out a number of outbound PIUs over a short period of time. However, if a second outbound PIU is sent over the network prior to the created inbound definite response PIU being received and discarded by the network, a protocol violation occurs. Protocol violations can also result for a number of other reasons when the above technique is employed.
This technique also involves the use of table look-ups. When a PIU is detected in the CAM by the NPM, the PIU and thus the session are interrupted until the PIU header can be read and a determination made as to whether or not the PIU should be intercepted and deleted or whether a new table entry should be created based on the source or destination of the PIU. Since this process involves looking through relatively large tables, throughput speeds and thus response times are subject to being significantly slowed.
For some users, the slower speeds and the occasionally lost sessions are merely annoyances. However, for other users, such as those in financial or military fields, the loss of an individual session may not be tolerable.